home *** CD-ROM | disk | FTP | other *** search
/ FishMarket 1.0 / FishMarket v1.0.iso / fishies / 351-375 / disk_359 / dice / compiler.doc < prev    next >
Text File  |  1992-05-06  |  7KB  |  197 lines
  1.  
  2.                    DICE SYSTEM
  3.  
  4.                   V2.0
  5.  
  6.                   Matthew Dillon
  7.                   891 Regal Rd.
  8.                   Berkeley, Ca. 94708
  9.                   USA
  10.  
  11.                   uunet.uu.net!overload!dillon
  12.  
  13.     Refer to doc/DCC.DOC for compiler options.
  14.  
  15.     Refer to doc/README.FIRST for copyright and shareware information.
  16.  
  17.     (1) SETUP
  18.  
  19.     You must purchase the amiga includes and amiga.lib from commodore
  20.     separately.  If you are a developer you ought to have these.  I
  21.     have not turned in my licence form to be able to distribute 1.3
  22.     includes yet, sorry!
  23.  
  24.     The preprocessor automatically scans the following directories:
  25.  
  26.     DINCLUDE:        location of top level includes such as stdio.h
  27.     DINCLUDE:Amiga/     location of amiga includes (e.g. amiga/exec/types.h)
  28.                 (amiga includes not included)
  29.  
  30.     DCC references startup and libraries to DLIB:
  31.  
  32.     DLIB:amiga.lib        A small-data model version of AMIGA.LIB (not included)
  33.     DLIB:c.lib        The main C library for which you have source code
  34.     DLIB:auto.lib        The auto library-open library
  35.     DLIB:c.o        The startup module
  36.     DLIB:x.o        The terminator module (for autoinit sections)
  37.  
  38.     (2) AMIGA.LIB
  39.  
  40.     You need to run the LIBTOS program on your AMIGA.LIB to produce a
  41.     small-data model AMIGA.LIB:
  42.  
  43.     libtos youramiga.lib DLIB:Amiga.lib
  44.  
  45.     This converts all absolute data references to base variables to
  46.     A4-relative references, allowing programs to be made residentable.
  47.  
  48.     (3) COMPILER EXECUTABLES
  49.  
  50.     Compiler executables should be made RESIDENT if possible.  DCC runs
  51.     DCPP, DC1, DAS, and DLINK.
  52.  
  53.     DCC        compiler front-end
  54.     DCpp        preprocessor
  55.     DC1        main compiler pass
  56.     Das        minimal assembler
  57.     DLink        linker
  58.  
  59.     --------------------------------------------------------------------------
  60.                 COMPILER FEATURES LIST
  61.  
  62.     (0) ANSI.  Pretty much ansi.  Please report non-ansism problems.
  63.  
  64.     (1) autos are placed in registers based on weighted usage.  A0,A1,D0,D1
  65.     will be used as register variables whenever possible, which usually
  66.     reduces the number of registers that must be saved/restored in
  67.     critical low level routines.
  68.  
  69.     (2) LINK/UNLK is removed from low level routines that do not reference
  70.     A5 and do not make any subroutine calls
  71.  
  72.     (3) MOVEM is converted to MOVE or deleted entirely
  73.  
  74.     (4) Various obvious optimizations:  use of BSET, BCLR, BTST as short
  75.     cuts to logic operations, CMP/TST, etc...
  76.  
  77.     (5) Switch() statements are optimized as follows:
  78.  
  79.         * if the range of values is less than double the number of cases
  80.           a lookup table will be used
  81.  
  82.         * otherwise subq/beq is used, but if the range of values is
  83.           within the size of a word then word operations will be used
  84.           instead of long operations.
  85.  
  86.     (6) Branch optimization.  Bxx to BRAs are optimized (up to 20 hops) by
  87.     DAS, and massive optimization is done to multi-level conditionals
  88.     by the main compiler pass
  89.  
  90.     (7) Workbench support.  The standard startup module supports the workbench.
  91.     Specifically, the low level _main() in c.o does this.
  92.  
  93.     When a program is run from the workbench, a different entry point is
  94.     called:     wbmain(wbmsg)
  95.  
  96.     If you do not supply a wbmain() then the one from the c.lib library
  97.     is used which immediately return(-1)s, exiting the program.
  98.  
  99.     (8) _main() shortcut for extremely low level programs.
  100.  
  101.     You may overide c.lib's _main with your own.  If you do so you may
  102.     not use any memory allocation, stdio, or fd (open,close...) related
  103.     routines.  The startup module (c.o) will still run autoinits,
  104.     autoexits, setup resident programs, and initialize your BSS space.
  105.  
  106.     _main(len, arg)     (as passed to the program on startup)
  107.     long len;
  108.     char *arg;
  109.     {
  110.     }
  111.  
  112.     If running from the workbench, you must GetMsg() and process the
  113.     workbench startup message yourself, as well return the message
  114.     when you exit.
  115.  
  116.     _exit exists in c.o and cannot be overridden.  If you use the _main
  117.     override you may NOT call exit() unless you also override it.
  118.     Calling exit() will generate references to stdio library code and
  119.     bring it in from the library, making your executable larger
  120.     unnecessarily.
  121.  
  122.     (9) AutoInit support.  You may qualify a subroutine with the _autoinit
  123.     keyword that will cause it to be automatically called by the
  124.     startup code rather than having to explicitly call it from main.
  125.  
  126.     This feature is more useful to bring code in indirectly.  For
  127.     example, to automatically OpenLibrary() (& CloseLibrary()) floating
  128.     point libraries if their base variables are referenced.  (p.s., fp
  129.     is not implemented in DICE yet).
  130.  
  131.     Refer to the auto.lib source code for examples.
  132.  
  133.     (10) DCC runs fast.  Make everything resident and watch it fly.  Most
  134.      of this speed comes from loading entire files into memory at once.
  135.      This might present a memory program though in general DCC will use
  136.      less memory than either Lattice or Aztec.
  137.  
  138.     (11) CODE SIZE is comparable with Lattice and Aztec, even better in
  139.      many cases.  The minimum program sizes are as follows:
  140.  
  141.     _main() { }          388    no stdio/fd
  142.      main() { }         2800    some stdio
  143.      main() { printf }  5200    most of stdio
  144.  
  145.     ------------------------------------------------------------------------
  146.                    COMMENTS
  147.  
  148.     Registerized parameters are not implemented.  Registerized parameters
  149.     work well only in a few limited cases.  In general, they do not add
  150.     much in the way of efficiency to small routines that do not get passed
  151.     much anyway, and must be moved or stored back onto the stack for larger
  152.     routines to allocate more critical local variables into registers, not
  153.     to mention complication to the caller.  A good implementation of
  154.     registerized parameters might put one or two parameters in registers.
  155.     Most implementations I have seen attempt to use all the scratch
  156.     registers and even some non-scratch registers.
  157.  
  158.     So, cute, but not as much of a boost as you might think.
  159.  
  160.     Inline library calls are not implemented either.  Inline library calls
  161.     are actually useful and when properly implemented increase efficiency
  162.     to low level calls such as AddHead() and GetMsg().  Other calls such as
  163.     Move() and Draw() do not increase noticably in efficiency.
  164.  
  165.     #pragma's must be used to define inline calls and this makes the compiler
  166.     enviroment less portable.  Lattice made a big mistake *requiring* the
  167.     use of inline library calls with residentable programs.  My solution was
  168.     to write a program to convert AMIGA.LIB into a small-data version of same.
  169.  
  170.     In general, I refuse to implement a thousand nearly useless features that
  171.     will only introduce more bugs into the compiler.
  172.  
  173.     ------------------------------------------------------------------------
  174.                 COMPATIBILITY
  175.  
  176.     Except for the lack of floating point and some Cisms that have not been
  177.     implemented yet (such as bit fields and floating point), DCC should
  178.     compile just about anything.
  179.  
  180.     I spent a great deal of time ensuring that STDIO routines run relatively
  181.     fast.  I decided to write nearly all of the support library in C instead
  182.     of falling back to optimized assembly to keep the system uniform.  One
  183.     does not notice much of a difference between the C strcpy() and an
  184.     assembly strcpy() relative to the run time of their program.  Currently,
  185.     however, the longword divide is sorely lacking.
  186.  
  187.     ------------------------------------------------------------------------
  188.  
  189.                 Your first program
  190.  
  191.     1> dcc examples/hello.c -o ram:hello
  192.     1> ram:hello
  193.     hello world
  194.     1>
  195.  
  196.  
  197.